image.png

数据迁移 往往 是数据运维经常会用到的事情，就像 pc重装电脑，把C盘的文件转移到E盘一样，不过 数据迁移 在生产环境当中往往是 跨网络 跨集群 传输 文件，要保证文件不丢失 不乱码 不重复 ，文件的完整统一。
【顺便需要解决 一下 pid 的存储路径，不然集群长时间 久了 突然停止，会停止不下来，报 找不到 NameNode 和DataNode】
http://blog.csdn.net/gyqjn/article/details/50805472

hadoop 集群数据 的特点是 量大 分块 有副本 ， 集群的稳定性 和配置高可用 机器 硬件性能 和网络带宽 stream 流读取等等都是考验。

hadoop 如果使用 get 把文件加载到本地，再通过scp 去传，不光步骤繁琐 ，小文件量大，在加上编写脚本容易出错 不易调试 ，集群不在同一内网，传输 速率和稳定性都无法保证。hadoop自然有一个自己的工具 ：Distcp .。假如 没有Distcp 想想 管理大数据 简直会是一个噩梦。
Distcp 的强大在于 简洁 可配置 传输稳定 原生支持 错误可以排查 等等，可以说是数据算法 及数据运维的福音。
当然 Distcp 很强大 ，也很傲娇，稍微不留意就会出现 小脾气和公主病，在倒腾 Distcp 的两周内，我也算吃了不少苦头，各种报错，简直不能忍，差一点就要放弃了，还是送我一片光阴 。尝到小甜头后，又继续报错 被虐的体无完肤，在最后的坚持下，提着头 抱着再解决不了干脆就离职跑路吧。但还是 强给自己信心。告诉自己没有踏不过坎都是纸老虎。

image.png

最终 克服重重困难 找到了 最终答案，回头一看，又气又恼，按道理是简单，可是找到宝藏 藏宝图不止一张，也只有不断的尝试后，才确认了最后的结果的正确性。

好了，言归正传，Distcp 支持 三种 协议 hdfs hftp webhdfs ，支持集群内部 拷贝，集群间拷贝 ，跨版本集群间拷贝。源和目标可以是目录 或者是文件 ，支持 overwrite 和update，Distcp 的执行 其实是mapreduce。
在使用 Distcp ，集群内部 src 源文件路径和dist 目标路径 都可以使用 hdfs 协议，例如
hadoop Distcp hdfs://master:9000/linkge/1020log.txt hdfs://master:9000/linkactive/1020log.txt

在集群间 数据迁移 ，单个 文件 ，需要在目标集群上操作，src源需要使用hftp 协议 默认端口 50070 ，dist 目标使用hdfs 协议 默认端口 9000 或者8020，
例如
hadoop distcp hftp://52.83.67.242:50070/linkpage/201707/01/01/biz.log.22.snappy hdfs://linkhadoop-master:9000/linkpage/201707/01/01/biz.log.22.snappy

单个目录也可以使用 此方式
hadoop distcp hftp://52.80.67.242:50070/linkpage/201707/01 hdfs://linkhadoop-master:9000/linkpage/201707/01

不过 对于拥有多个大文件的单个目录来说，使用hftp 协议传输 会报一些错误 ，好像是hadoop 2.x 自带的老bug
这些错误包括socket read time out 和 文件 读写和文件大小不统一
`
Caused by: org.apache.hadoop.tools.mapred.RetriableFileCopyCommand$CopyReadException: java.net.SocketTimeoutException: Read timed out

Caused by: java.net.SocketTimeoutException: Read timed out

Caused by: org.apache.hadoop.tools.mapred.RetriableFileCopyCommand$CopyReadException: java.io.IOException: Got EOF but currentPos = 1900544 < filelength = 3461794346
at org.apache.hadoop.tools.mapred.RetriableFileCopyCommand.readBytes(RetriableFileCopyCommand.java:290)
at org.apache.hadoop.tools.mapred.RetriableFileCopyCommand.copyBytes(RetriableFileCopyCommand.java:258)
at org.apache.hadoop.tools.mapred.RetriableFileCopyCommand.copyToFile(RetriableFileCopyCommand.java:183)
at org.apache.hadoop.tools.mapred.RetriableFileCopyCommand.doCopy(RetriableFileCopyCommand.java:123)
at org.apache.hadoop.tools.mapred.RetriableFileCopyCommand.doExecute(RetriableFileCopyCommand.java:99)
at org.apache.hadoop.tools.util.RetriableCommand.execute(RetriableCommand.java:87)
`

这些错其实并不能说明是src 集群 文件是有问题的，所以 经过多次 尝试 仍然无法解决，多个文件传输 仍有 70%的文件传输失败。
这个问题 最终在 Google一个非常难查到的网页找到了微弱的声音，当看到页面 有一个 solved ，真是百感交集。
https://community.cloudera.com/t5/Storage-Random-Access-HDFS/Handling-Distcp-of-large-files-between-2-clusters/td-p/42470
有人 跟帖告诉大家使用 webhdfs 协议可以几乎完美的解决这个问题，数据总算是可以愉快的传输了。

例如
hadoop distcp webhdfs://52.82.67.242:50070/linkpage/201708 hdfs://linkhadoop-master:9000/linkpage/201708

刚才说的 这些 是在使用的Distcp 终极答案。其中在使用Distcp 中途还遇到了 其他的拦路鬼，
比如报 在 src 集群 的DataNode无法找到相应的文件，
这个 一般来说src 集群本身的问题， 比如说 集群 中各个节点有没有设置 主机名，每个DataNode 节点 是否 在/etc/hosts 配置了 所有src DataNode NameNode的 节点 的私有ip 与主机名及dist 目标集群 的DataNode NameNode 节点的公有ip 和主机名，而且 dist 目标集群也要 做类似配置。要配置 ssh免登陆，NameNode ssh免登陆到DataNode上，配置一下 hadoop 各个节点 守护进程 的pid 目录，配置 hadoop 用户 下的 ~/.bashrc 文件中的环境变量，重启集群试试

还有其他的 socket 连接 时间超时，怀疑可能是 网络带宽，还有读大文件的异常，很有可能是 内存小 硬盘性能问题等等。如果可以做配置更改也是很不错的。

另外 我们要有能力定位问题 ，查找问题 ，搜索答案 ，解决问题。验证问题 验证解决方案。

比如我们在使用 Distcp 传输的时候时，先小数据集 验证，
比如定位到一个文件 ，多次传输 ，观察 传输的稳定性，和传输后的文件大小和行数，
再 单目录 传输，观察 目录文件的数量是否一致，文件的大小是否一致，量多的话，选择抽查 部分文件 查看行数是否一致。也可以通过 head tail命令查看 前后十行文件内容是否一致
源集群 抽查 部分文件行数

image.png

目标集群抽查相同的部分文件行数

image.png